Skip to content

Conversation

@Gusandr
Copy link

@Gusandr Gusandr commented Jan 18, 2026

Added a test to verify that the built-in classes wrapping Vector128 are functioning correctly and that values are being passed through registers

KT-57335

Add a regression test to verify that inline classes wrapping Vector128 work correctly and values are passed via registers.

^KT-57335 Fixed
@Gusandr Gusandr requested review from a team as code owners January 18, 2026 23:04
@Gusandr
Copy link
Author

Gusandr commented Jan 21, 2026

@kunyavskiy I'm not sure if entering Experimental into the compilation arguments and annotation in the box() method is correct (I looked at the code of the tests nearby), I would like to hear your opinion on how best to implement this little test

}

return "OK"
} No newline at end of file
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea of adding such a test is to prevent the original crash from happening again. That means that the code should crash when compiled and run with Kotlin 1.8.10. Does this happen?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the test to use a single-file structure, strictly matching the original reproduction case. The test should now reliably fail if the regression recurs

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you check the code from the test with Kotlin 1.8.10? Does it crash?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I verified it manually on Windows x64 using the 1.8.10 standalone compiler

The application crashes silently at runtime. It produces no output and terminates immediately with exit code -1073741819 (which corresponds to 0xC0000005 - Access Violation)

This confirms the test accurately reproduces the regression as a hard crash on the target platform

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have just checked it, and it doesn't crash for me. Which source code did you compile, with which flags?

At the very least, it means that the test doesn't reliably reproduce the crash.

The problem is most likely specific to the stack pointer alignment when entering the box function. So, depending on the caller frames, the same code may crash or not crash.

All this affects the usefulness of the test. It should reliably reproduce the issue, regardless of the caller frames and other context. I can imagine you can achieve that by calling the problematic code multiple times, having different stack frame sizes in the caller.

Please experiment with that.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the insight regarding the stack pointer alignment! I have updated the test to ensure reliability:

Introduced a recursive function confuseStackAndRun(depth: Int) to shift the stack pointer

The test now iterates through recursion depths from 0 to 10

This approach forces the runtime to execute the problematic code with various stack alignments, ensuring the crash is triggered regardless of the initial caller frame

}

return "OK"
} No newline at end of file
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have just checked it, and it doesn't crash for me. Which source code did you compile, with which flags?

At the very least, it means that the test doesn't reliably reproduce the crash.

The problem is most likely specific to the stack pointer alignment when entering the box function. So, depending on the caller frames, the same code may crash or not crash.

All this affects the usefulness of the test. It should reliably reproduce the issue, regardless of the caller frames and other context. I can imagine you can achieve that by calling the problematic code multiple times, having different stack frame sizes in the caller.

Please experiment with that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants